< previous page page_222 next page >

Page 222
Okay, maybe this second interpretation is a bit of a stretch and not particularly intuitive. However, it does match the behavior of this function. The GetMappedInfo function in the MapInfol.vbp project can be rewritten as follows to allow multiple attempts:
7017a6ead0e3c4111b47a554df321e9f.gif
Do
   Buffer = String$(BufferLength, 0)
   res = WNetGetConnection(Drive, Buffer, BufferLength)
Loop While res = ERROR_MORE_DATA
BufferLength starts at 0 with an empty Buffer string parameter. Each time the WNetGetConnection function returns ERROR_MORE_DATA, the buffer length is increased to the current estimated buffer length, and another attempt is made to call the function.
The Microsoft Win32 API documentation is the standard reference for API function calls. But even when you read it carefully, you will probably find yourself experimenting occasionally to determine exactly what the function calls do.
The Second Approach
Another common approach to handling this type of problem is potentially more efficient. Simply set the Buffer string to a very large value before calling the WNetGetConnection API function for the first time. You'll want to test for the ERROR_MORE_DATA error just in case, though if your string is set to a length of at least MAX_PATH bytes (constant MAX_PATH is 260), odds of this error occurring are slim.
If you take this approach, you'll need to find the end of the string by using the Instr function to find the NULL termination character and throwing away everything from that character to the end of the string. In the MapInfol.vbp example, the BufferLength variable is loaded with the length of the buffer. Since the final character is the NULL termination character, the Left$ function can be used to retrieve the string to the left of that character.

 
< previous page page_222 next page >